Mackerelを使ったAWSリソース監視でお気に入り機能を書いていく
はじめに
こんばんわ、札幌のヨシエです。 当ブログはMackerel Advent Calendar 2019の10日目エントリとなります。
自分自身がこれまでAWSの監視でMackerelを使ってきたのか書きたいと思います。
基本としてはAgentにプラグインを実装することで様々な視点で監視が実現できる点で非常に使い勝手が良い分、秘伝のタレになることは好ましくないことからカスタマイズされたプラグインの使い方は端折って記載させていただきます。
目次
監視ルート図解
大まかではありますが、Mackerelで使用できる監視方法を図で書いてみます。
AWS環境リソース監視
Mackerelでは長い間、使用され続けている「Agent監視」と「インテグレーション監視」の2種類をサポートしております。基本的にはこちらのリソース監視を行うことが多いイメージでした。
Agent監視
Agent監視は様々な監視ソリューションでも利用することが可能な監視用Agentを監視対象にインストールし、Agent自身が様々なリソース情報をかき集めて監視する方法です。
MackerelでのAgent監視
MackerelでAgent監視を行うためにはmackerel-agentをEC2にインストール、オーガニゼーションに払い出されたAPIキーを設定ファイルに書き込むことでリソース状況の取り込みができるようになります。
mackerel-agent-plugins
mackerel-agentは公式としてプラグインが用意されており、このプラグインを使用すると設定されているインスタンスのリソース画面にカスタムメトリクスとして表示されます。
様々なミドルウェアで使用できるプラグインが存在しますが、私は以下のプラグインを使うことがしばしばあります。
| プラグイン名 | 使途 |
|---|---|
| mackerel-plugin-aws-ec2-cpucredit | T2 or T3系インスタンスで確認で使用するCPUCredit確認用 |
| mackerel-plugin-inode | ディスク使用量はmackerel-agent、inode使用率を取得 |
go-check-plugins
mackerel-agent-pluginとは別にgo-check-pluginsと呼ばれるプラグインも存在します。
これは/usr/bin配下にチェック用スクリプトが配置され、mackerel-agent.confでコマンドを実行する形で設定を行うことにより、agentがインストールされているサーバー自身の状態を監視することが可能です。
このプラグインを使用することでリソース以外の監視が実現できるため、ログファイルでcriticalログが頻発したなどを検知することが出来ます。
注意点
各AWSサービスのリソース状況はインターネットを経由してPUTされるのでインターネットへの疎通がないEC2監視などではNATGatewayの配置やポートの開放、Squidなどのプロキシを配置する必要があります。
どのような監視が良いのか？
基本はmackerel-agentによるリソース監視をメインとするだけで問題ないと考えており、これは設定方法の違いを考慮しました。
mackerel-agent-pluginsとgo-check-pluginsは各サーバーホストに対して設定を投入する必要があるので設定変更時にはmackerel-agent.confの設定変更が必要となります。
ホスト内の設定ファイル変更は数台の構成やスケーリングが行われないシステムではコストは低いですが、多数のホストや頻繁にスケーリングが発生するシステムではAMIに設定ファイルを仕込んだりS3に配置してインスタンス起動時にuserdataによるファイル取得をするといったひと手間を加える観点があります。
このような作業は何かしらミスに繋がりやすいことからバックアップ/構成変更時に発生するコストを許容されるサーバー以外にはmackerel-agentのみの構成が良いか思います。
インテグレーション監視
インテグレーション監視はCloudWatchメトリックを取得してMackerelによる監視を行うことが出来る方法です。
Mackerelでのインテグレーション監視
インテグレーション監視を行うためにはMackerelがCloudWatchからメトリック情報を取得できる必要があるので、監視対象に応じたIAMロールを作成することで監視を開始することが出来ます。
監視可能サービス
公式HPを参照するのが手っ取り早いと思います。
注意点
IAMロールへ付与する権限は基本的にReadOnlyAccessであること、また1つのIAMロールに対して付与できるポリシー数が10個までとなるので「CloudFront」,「EC2インスタンス」,「Serverless」が一つのAWSアカウントに集約されている環境で全ての監視を行うときにはインテグレーションを分ける必要が出てくるのでご注意ください。
EC2内部でスクリプト等によるメトリックPUTで出力されたカスタムメトリックはCloudWatch上には表示されますが、Mackerelでは取り込めませんので必要なメトリックがある場合はmackerel-agent監視に切り替える必要があります。
外形監視
Mackerelから指定されたURLへリクエストを投げこみ、ステータスコード200 or 300で帰ってくることを監視します。
Web系システムやAPIを提供するサービスでは特に大事な部分であり、HTTP/HTTPSをサポートしている観点から外せない監視方法と考えております。
サービスメトリック監視
特に面白い機能であるサービスメトリックはサーバー等で取得した値をMackerelへPUTすることで可視化することが可能になります。
「値をPUT」のみでグラフが作成されるので、例として使われるパターンが多いログの行数監視では非常に重宝します。
ロール内異常検知
予めロールとしてに参加しているリソースの使用状況を機械学習にて学習、気付きづらい負荷や前週と異なる負荷に気づくことが出来ます。
ロール内異常検知は社内で利用されるナレッジサーバーを監視対象として使わせて頂きましたが、想定している以上に検知性能が良いので「リソース消化の予測が立てづらい」といった場面で役に立つ機能と考えております。
検証結果は以下の記事にて記載しているので見ていただけると幸いです。
最後に
これまでMackerelを触ってきた限り、お気に入りの監視機能を書き出してみました。 全てのサービス活用が実現できているわけではないので、継続して発信していきたいと思います。
